1. Exploring Mobile Access Scenarios
When and how users will access information on mobile
devices will differ based on your specific implementation, the level of
participation of users involved with the data, and the security
requirements for accessing the data. This section explores three primary
access scenarios to illustrate when you might consider using each.
These scenarios are
Anonymous users connecting through mobile browsers
Authenticated users connecting to internal resources from mobile devices across a firewall
Authenticated users connecting to internal resources from mobile devices through a secure access gateway
1.1. Anonymous Mobile Browser Access
Although this type of
access is usually associated with publishing sites, and even more
specifically with Internet-facing sites, anonymous mobile browser access
is still a common access scenario worth covering. In this scenario, the
user with the mobile device connects from the Internet while the Web
front-end (WFE) server might be located in the perimeter networks. The
firewall configuration for this scenario can be similar to a
configuration for granting access to authenticated users.
Keep in mind the following main points about this configuration.
The user is connecting from the public network (Internet).
The user is connecting to a SharePoint site that is already addressable publicly.
The user is connecting anonymously, so no authentication considerations exist.
1.2. Authenticated Cross-Firewall Access
Cross-firewall access
refers to a scenario by which SharePoint sites are published externally.
In this case, the user is connecting from the Internet with anonymous
access and can also connect as an authenticated user with contributor
access to data within SharePoint sites. The user might be connecting
using a mobile browser, or they might be using a mobile access client
such as Office SharePoint Workspace Mobile 2010. There are a variety of
firewall options for this type of setup, the most secure of which is a
back-to-back firewall configuration in which the serving WFE is located
in the perimeter network. This might not always be possible, however,
and many organizations have already invested in their infrastructure for
serving traffic to Internet requestors. Consider the following points
when configuring cross-firewall mobile access.
The user is connecting from the public network (Internet).
The user is connecting to a SharePoint site that may or may not be publicly addressable.
The server may be located behind one or more firewalls.
The user will be authenticated, perhaps even as a contributor.
SSL is recommended to ensure the security of authentication information.
1.3. Authenticated Secure Gateway Access
In this final scenario for mobile access, assume that there is a server or device acting as a reverse
proxy, which is handling requests on behalf of users in a secure
manner. This server or device might be handling the authentication of
users as well as encrypting user connections. This server or device
might be the lone firewall, or it might be a secondary firewall
solution, the latter of which is far more secure. When implementing this scenario, keep the
following considerations in mind.
The user is connecting from the public network (Internet).
The user will be authenticated, perhaps even as a contributor.
The user is connecting to a SharePoint site that may or may not be publicly addressable, through the secure access gateway.
The secure access gateway may be located behind one or more firewalls.
SSL is recommended to ensure the security of authentication information.
SSL encryption may be handled by the secure access gateway solution.
2. Examining Common Firewall Configurations
To facilitate secure external access for mobile
devices, you can employ a variety of different firewall configurations.
Many organizations have already implemented security and firewall
solutions that facilitate the separation of their internal and perimeter
networks from the public Internet. Usually, you will find that you can
leverage existing implementations when providing mobile access. However,
depending on the existing setup, in some cases additional security
concerns may lead you to re-evaluate your current solutions, after which
you may find that additional firewall devices or network segmentations
are necessary. This section reviews the following three example
configurations, which are considered typical.
The Internet Edge Firewall Solution
The Multi-homed Firewall Solution
The Back-to-Back Firewall Solution
Many mobile devices also offer one more possibility—the ability to connect to internal network resources using a secure Virtual
Private Network (VPN) connection. Although this might seem like a quick
and easy way to deploy access for mobile devices, this option opens up a
myriad of issues that could cause additional security concerns. For
example, when a device has access to a network through a VPN,
it is likely to have an internal network address and possibly have
access to additional network resources (depending on the configuration)
in addition to the intended SharePoint sites. Security breaches such as
these pose potential problems when mobile devices with access through a
VPN are procured and operated directly by the end user, because the
vulnerability of the internal network increases through the use of
unauthorized software or the introduction of a virus or malware. Remote
access through a VPN also does not satisfy the requirements of the three
access scenarios described in the previous sections. Specifically,
remote VPN access cannot facilitate anonymous access to sites. In
addition, VPN access for mobile devices can prove significantly slower
than the firewall solutions described previously, because most VPN
solutions employ to encryption and compression methods that add
processing time.
2.1. Edge Firewall
Figure 1
illustrates an example of an edge firewall configuration. Notice that
there is only a single firewall device standing between the Internet and
the internal network. Also notice that both the SQL back-end server and
the WFE servers are on the same network—the internal network. Of
course, this increases the security risks associated with this
configuration for two reasons: (1) There is a single point of failure
with only one firewall; and (2) should the WFE become compromised, it
can allow access to the entire internal network. For these reasons, you
should consider this configuration only as a last resort—even though it
is currently the most common configuration found in small to mid-sized
enterprises.
2.2. Multi-homed Firewall
Figure 2 illustrates an example of a multi-homed
firewall configuration. Notice that there is only a single firewall
device standing between the internal and public networks in this
configuration, as in the edge firewall configuration. What
differentiates the multi-homed firewall configuration from the edge
firewall configuration is the addition of the perimeter network. The
perimeter network may or may not share a physical network segment with
the internal network, but at the very least, it must be on its own
logical network or VLAN.
The diagram in Figure 2
shows that the SQL back-end and WFE servers are on the same network,
although this does not necessarily need to be the case. Traffic from the
WFE can be routed to the SQL back-end server by way of the firewall
device as well, although this does require additional configuration.
The multi-homed
configuration shares a limitation with the edge firewall
configuration—here again there is a single point of failure because
there is only one firewall device. However, the multi-homed
configuration is more secure than the edge firewall configuration in the
way that traffic is routed to the SharePoint servers from the Internet.
Since the internal and perimeter networks remain separate, even if only
logically, a compromised WFE server would not have unlimited access to
internal network resources. For these reasons, this configuration is
preferable to that of the edge firewall, but it is still not quite as
secure as the back-to-back
firewall configuration, which is described in the next section. The
multi-homed configuration is common in mid-sized enterprises, where
resource constraints often limit the complexity and cost of firewall
implementations.
2.3. Back-to-Back Firewall
Figure 3 illustrates an example of a back-to-back firewall configuration. Notice that there are two firewall devices
standing between the internal and public networks. What differentiates
the back-to-back firewall configuration from that of the edge and
multi-homed firewall configurations is the additional separation of the
internal and perimeter networks. The perimeter network is completely
separate from the internal network, with all traffic from the Internet
restricted to servers located on the perimeter network.
In this configuration, the
firewall rules on the primary or external firewall are less restrictive,
to allow traffic from the Internet to reach the WFE servers. The
firewall rules on the secondary or internal firewall are far more
stringent, which greatly restricts traffic from the servers located on
the perimeter network. The diagram in Figure 3
shows the separate SQL back-end and WFE servers networks, with the
traffic coming from the WFE allowed to pass through the secondary
firewall.
The key to the security of this
configuration lies in the fact that the secondary firewall allows this
traffic to pass only if it originates on the perimeter network servers.
Additionally, the address and server name information are completely
concealed from the public network, making it impossible to directly
address any resources located on the internal network from the Internet.
This firewall configuration is considered the most secure of the three
configurations presented here, because it adequately segments and
controls the traffic between all three networks and reduces the exposure
to a single point of failure. This configuration is often found in
larger organizations and is particularly common in SharePoint
implementations where extranet access or Internet-facing sites are
present.
2.4. Secure Access Gateway Configuration
Microsoft Forefront Unified
Access Gateway (UAG) incorporates many of the features previously found
in Microsoft Internet, Security, and Acceleration (ISA) server. For the
purposes of this section, you will review the implementation of UAG as a
complement to the previously described firewall configurations, because
UAG can be used as a stand-alone gateway with the edge firewall
solution, as an addition to a multi-homed firewall configuration, or as a
back-end firewall.
The main
difference between implementing these three firewall configurations with
or without UAG is the location of the SharePoint servers when
authenticated access is provided to external users. By implementing UAG
as a secure access gateway solution, SharePoint servers can be located
entirely on the internal network, which is arguably the most secure
place for them. This location may be where the servers were initially
implemented, as is often the case for a collaboration-centric
implementation. Figure 4
illustrates this configuration variation, showing the SharePoint
servers located on the internal network. Of course, locating the
SharePoint servers on the internal network will not work if your
requirements include extranet access for users who will not be
authenticated by the UAG gateway, or anonymous access for users of
Internet-facing sites. In these cases, the servers should be located in
the perimeter network, even if the UAG gateway remains present to
provide secure access to a subset of authenticated users.
In the case of an
implementation in which a UAG gateway is added to an existing
multi-homed or back-to-back firewall configuration, you could add the
UAG server to complement the configuration, with the intent to
eventually move the SharePoint servers from the perimeter network to the
internet network if external access requirements allow the change.
The next section details
the step-by-step configuration you will need for a UAG solution that
will allow authenticated access on mobile
devices. You will examine how the configuration should be set up on the
UAG server and the configuration required on the SharePoint farm. As is
the case in prior versions of ISA server, it is still possible to use
UAG as a traditional firewall stand-in for one of the configurations
discussed by creating a simple Web Listener and Firewall Policy
Publishing Rule for such access. This section does not review this
traditional option because it does not differ significantly conceptually
from that of a traditional third-party hardware-based reverse
proxy/firewall solution. The focus of the next section is instead on the
new secure access gateway setup provided by Microsoft Forefront UAG
server.
